IBIS Macromodel Task Group Meeting date: 11 June 2013 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Brad Brim Kumar Keshavan Ken Willis Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Hassan Rafat Ron Olisar Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. James Zhou SiSoft: * Walter Katz * Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Walter: We should discuss open forum votes and editorial process -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Fangyi to get clarification of retimer flow ready for Friday. - Done ------------- New Discussion: Interconnect update: - Michael M: There was no meeting last week - There will be a meeting this week IBIS 6.0: - Michael M showed a list of new BIRDs in IBIS 6.0 - Michael M: Currently it is being called IBIS 6.0 but we need to discuss numbering strategy - Walter: We need to start the editorial process - Radek: I can help - Bob: BIRD 156.2 should be upgraded to 156.3 - Michael M: That will happen shortly, with changes folded in - Walter: BIRD 145 was discussed and tabled for the interconnect group to handle - BIRD 158 was not voted at the last open forum - Radek and I will work on that offline - Ambrish had raised objections to the BIRD - BIRD 161 will be discussed in interconnect - BIRD 150 & 155 are two ways to handle dependencies - We have to decide what to do about back channel BIRD 147, BIRD 128 is related - BIRD 125 needs to be discussed - Michael M: A draft 6.0 is ready, can be posted in the minutes - The draft was easy to assemble in the new format - The IBIS Version Change Strategy document: http://www.eda.org/ibis/docs/ibis-version-change-strategy-v3p0.pdf (an XLSX is also available) - The WIP IBIS Ver. 6.0 draft is available at http://www.eda.org/ibis/ver6.0_wip/ - Arpad: Why is there a comment about IBIS 5.2? - Michael M: It is a placeholder, will be deleted - Walter: When will we have a 6.0 parser? - Michael M: We need to start the bidding process - Arpad: I am concerned about a new developer being unfamiliar with the code - Bob: It probably will take months to get started and months to complete - Michael M: The process can begin fairly soon - Bob: We will need to assure funding - Bob: One option is to suspend interconnect meetings and use the time slot again - Michael M: If there is no objection - Ambrish: Are all of the changes folded in? - Michael M: Yes but there are some outstanding issues Backchannel: - Arpad: Is there any news on BIRD 147? - Ambrish: It was shared in March, not revisited since - There will be an update next week - We should all review the current BIRD - Walter: BIRD 128 can be combined with BIRD 147 - Bob: BIRD 128 is just one page, that should be OK - Both BIRDs are written against IBIS 5.0 though - Arpad: They can be rewritten against 6.0 - Arpad: It is a problem that we are changing the in/out argument usage in BIRD 128 - It may be better to add a new argument - Radek: Agree, we should work on this - Arpad: There may be backward compatibility problems - Radek: We have AMI_Version to handle that - Arpad: We will discuss this next week AR: Ambrish update BIRD 147 Dependency Tables: - Walter: The BIRD 150 functionality is well understood - BIRD 155 takes the idea that tables are not flexible enough - There will be memory management issues, plus in/out issues - Dependency table changes will require a new DLL, not just an AMI change - We could implement either BIRD, or both - Radek: BIRD 155 should be easily updated soon - Arpad: BIRD 155 avoids having to explain BIRD 150 table operation - Any new features required will not require a spec update - Radek: Fangyi may not be available next week - Walter: We should have model maker feedback - David: Altera prefers the DLL approach - It also helps protect IP - Mike L: It is easy to determine every possible mapping by probing - David: The logic behind the mapping can still be concealed AR: Arpad contact Fangyi about BIRD 155 updates Eye Mask Definition: - Arpad: We need to resolve the timing side of this - Michael M: There was a proposal in this from Japan - Is this for pass/fail testing? - Arpad: It is for BER - Michael M: I wonder if a pass/fail spec is useful - Arpad: We could have multiple eye masks, for different BER levels - Rx_Receiver_Sensitivity is a poor man's eye mask, we need a full fledged one - Ambrish: Rx_Receiver_Sensitivity is not an eye mask - Arpad: It needs to have a timing component added - Walter: That is handled by Clock_PDF - Rx_Receiver_Sensitivity is like Vdiff - This is an interesting topic, but it opens a Pandora's Box of issues - Arpad: This is at the other side of the model - Walter: Is this for legacy models? - Arpad: They are not clocked - Michael M: We may simply not be documenting the clocking, but it may still exist - Arpad: We can't deal with eye masks for legacy models - Somehow we never introduced that concept - Walter: DDR4 has eye mask rules - There should be a BIRD for that - An AMI model should be usable within any standard - These rules should belong to the standard, not the model - Arpad: Why is Rx_Receiver_Sensitivity in the spec? - Walter: That is the silicon itself - Ambrish: What does Rx_Receiver_Sensitivity do? - Arpad showed that portion of the spec - Arpad: Where is this measured? - David: It has to be measured at the ball - Walter: Some chips gives scope readings at the decision point - David: The signal at the slicer is not part of the standard - Ambrish: Rx_Receiver_Sensitivity only helps determine the BER - Walter: In combination with Clock_PDF ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives